Celestin Apprentice 2/Apprentice-Release2.iso/Information/Digests/CSMP Digest/volume 1/csmp-v1-197.txt

Text File | 1994-12-08 | 52.1 KB | 1,470 lines | [TEXT/R*ch]

C.S.M.P. Digest             Mon, 26 Oct 92       Volume 1 : Issue 197

Today's Topics:

    Can I tell if MacsBug is installed?
    Patching MBDF
    SUIT - anyone try it? (Simple User Interface Toolkit)
    Is a resource fork already open?



The Comp.Sys.Mac.Programmer Digest is moderated by Michael A. Kelly.

The digest is a collection of article threads from the internet newsgroup
comp.sys.mac.programmer.  It is designed for people who read c.s.m.p. semi-
regularly and want an archive of the discussions.  If you don't know what a
newsgroup is, you probably don't have access to it.  Ask your systems
administrator(s) for details.  (This means you can't post questions to the
digest.)

Each issue of the digest contains one or more sets of articles (called
threads), with each set corresponding to a 'discussion' of a particular
subject.  The articles are not edited; all articles included in this digest
are in their original posted form (as received by our news server at
cs.uoregon.edu).  Article threads are not added to the digest until the last
article added to the thread is at least one month old (this is to ensure that
the thread is dead before adding it to the digest).  Article threads that
consist of only one message are generally not included in the digest.

The entire digest is available for anonymous ftp from ftp.cs.uoregon.edu
[128.223.8.8] in the directory /pub/mac/csmp-digest.  Be sure to read the
file /pub/mac/csmp-digest/README before downloading any files.  The most
recent issues are available from sumex-aim.stanford.edu [36.44.0.6] in the
directory /info-mac/digest/csmp.  If you don't have ftp capability, the sumex
archive has a mail server; send a message with the text '$MACarch help' (no
quotes) to [e-mail] for more information.

The digest is also available via email.  Just send a note saying that you
want to be on the digest mailing list to [e-mail], and you will
automatically receive each new issue as it is created.  Sorry, back issues
are not available through the mailing list.

Send administrative mail to [e-mail].


-------------------------------------------------------

From: [e-mail] (Jason Jones)
Subject: Can I tell if MacsBug is installed?
Organization: University of Chicago Computing Organizations
Date: Fri, 18 Sep 1992 23:02:47 GMT

I'm writing an assert() macro.  When an assertion fails during execution, I'd
like the assertion handler to enter MacsBug, if it is installed (displaying
relevant information via _DebugStr), or display the same information in a
dialog box if MacsBug is not present.

So, how do I tell if a low-level debugger is installed?  Comparing the address
of the _Debugger or _DebugStr traps to the address of _Unimplemented didn't
work.  Any suggestions?

Also, would anyone be interested in a version of printf that prints to MacsBug
instead of stdout, or a version of sprintf that builds Pascal strings?  Or
did somebody do this a long time ago ...

jason.

+++++++++++++++++++++++++++

From: [e-mail] (Kent Sandvik)
Date: 20 Sep 92 18:59:48 GMT
Organization: Apple

In article <[e-mail]>,
[e-mail] (Jason Jones) wrote:
> I'm writing an assert() macro.  When an assertion fails during execution, I'd
> like the assertion handler to enter MacsBug, if it is installed (displaying
> relevant information via _DebugStr), or display the same information in a
> dialog box if MacsBug is not present.

> So, how do I tell if a low-level debugger is installed?  Comparing the address
> of the _Debugger or _DebugStr traps to the address of _Unimplemented didn't
> work.  Any suggestions?

The information is available in the MacsBug Referenceand Debugging Guide.
When a system error or 68000 exception occurs, the ROM code examines the
global variable MacJmp to obtain the address of the debugger's entry point.

If you are running under 24-bit mode, the high-order byte of MacJmp is a
flags byte that contains the following information:

Bit     Meaning
7       Set if debugger is running
6       Set if debugger can handle system errors
5       Set if debugger is installed
4       Set if debugger can support the Discipline utility

The lower 3 bytes of MacJmp (x120) are used to store the address of the
debugger's entry point.

If you are running under a 32-bit Memory Manager, the flags byte is moved
to address $BFF and the long word at MacJmp becomes a full 32-bit address
that points to the debugger's entry point.

As for macros, here's something I use a lot in my code:
// MACROS
// ASSERT Function, used for testing conditions and flagging error states.
#ifdef TESTING
#define        ASSERT(condition,debugMsg)        ((void) 0)
#else
#define        ASSERT(condition,debugMsg)        ((condition) ? (void) 0 :
DebugStr(debugMsg))
#endif

> Also, would anyone be interested in a version of printf that prints to MacsBug
> instead of stdout, or a version of sprintf that builds Pascal strings?  Or
> did somebody do this a long time ago ...

Mark Lanett posted this recipe some time ago:
void vdebugstr(char* format,...) {
    char buff[257];
    va_list arglist;
    vs_start(arglist,format);
    vsprintf(buff,format,arglist);
    va_end(arglist);
    DebugStr(c2pstr(buff));
}

vdebugstr("Hey, index %i is not in range 0..31",index);

Kent Sandvik/DTS
"You should really just relax" -MST3K
- -------------------
Kent Sandvik (UUCP: ....!apple!ksand; INTERNET: [e-mail])
DISCLAIMER: Private activities on the Net.

+++++++++++++++++++++++++++

From: [e-mail] (Keith Rollin)
Organization: Taligent
Date: Sun, 20 Sep 1992 23:36:09 GMT

In article <[e-mail]>, [e-mail] (Kent
Sandvik) wrote:
>
>In article <[e-mail]>,
>[e-mail] (Jason Jones) wrote:
>> I'm writing an assert() macro.  When an assertion fails during execution, I'd
>> like the assertion handler to enter MacsBug, if it is installed (displaying
>> relevant information via _DebugStr), or display the same information in a
>> dialog box if MacsBug is not present.
>>
>> So, how do I tell if a low-level debugger is installed?  Comparing the address
>> of the _Debugger or _DebugStr traps to the address of _Unimplemented didn't
>> work.  Any suggestions?
>
>The information is available in the MacsBug Reference and Debugging Guide.
>When a system error or 68000 exception occurs, the ROM code examines the
>global variable MacJmp to obtain the address of the debugger's entry point.
>
>If you are running under 24-bit mode, the high-order byte of MacJmp is a
>flags byte that contains the following information:
>
>Bit     Meaning
>7       Set if debugger is running
>6       Set if debugger can handle system errors
>5       Set if debugger is installed
>4       Set if debugger can support the Discipline utility
>
>The lower 3 bytes of MacJmp (x120) are used to store the address of the
>debugger's entry point.
>
>If you are running under a 32-bit Memory Manager, the flags byte is moved
>to address $BFF and the long word at MacJmp becomes a full 32-bit address
>that points to the debugger's entry point.
>

Unfortunately, the description in the Macsbug manual on when to check $120
and when to check $BFF sucks the biggie. It's not clear on whether it's
talking about:

o Running on a machine with a ROM containing a 32-bit Memory Manager,
o Running on a machine that booted into 32-bit mode, or
o Running on a machine whose CPU is in 32-bit mode because someone called
  SwapMMUMode.

I recently looked into Macsbug, and feel that the following is the right
way to determine if the debugger flags are at $120 or $BFF. First, look at
$BFF. If there is an $FF there, then the flags are at $120. If the value at
$BFF is not $FF, then treat them like valid debugger flags.

- -----
Keith Rollin
Phantom Programmer
Taligent, Inc.

---------------------------

From: [e-mail] (Brad Morris)
Subject: Patching MBDF
Date: 16 Sep 92 15:27:11 GMT
Organization: University of Chicago Computing Organizations

I am trying to write some code to patch the MBDF.  I know about the MBDF handle
in low memory, but how to I stop LoadResource from loading the Apple MBDF
over mine.  I am kind of new at mucking around in this way.  Thanks.

Brad Morris
[e-mail]

+++++++++++++++++++++++++++

From: [e-mail] (Keith Rollin)
Date: 17 Sep 92 18:51:56 GMT
Organization: Taligent

In article <[e-mail]>,
[e-mail] (Brad Morris) wrote:
>
> I am trying to write some code to patch the MBDF.  I know about the MBDF handle
> in low memory, but how to I stop LoadResource from loading the Apple MBDF
> over mine.  I am kind of new at mucking around in this way.  Thanks.
>

Won't InitProcMenu work? When the Menu Manager calls LoadResource, I think
it doesn't it with the res ID in the MenuList, which is set by the value
passed to InitProcMenu.

- -----
Keith Rollin
Phantom Programmer
Taligent, Inc.

+++++++++++++++++++++++++++

From: [e-mail] (Brad Morris)
Date: 18 Sep 92 22:51:07 GMT
Organization: University of Chicago Computing Organizations

In article <[e-mail]> [e-mail] (Keith Rollin) writes:
>In article <[e-mail]>,
>[e-mail] (Brad Morris) wrote:
>>
>> I am trying to write some code to patch the MBDF.  I know about the MBDF handle
>> in low memory, but how to I stop LoadResource from loading the Apple MBDF
>> over mine.  I am kind of new at mucking around in this way.  Thanks.
>>
>
>Won't InitProcMenu work? When the Menu Manager calls LoadResource, I think
>it doesn't it with the res ID in the MenuList, which is set by the value
>passed to InitProcMenu.
>
>-----
>Keith Rollin
>Phantom Programmer
>Taligent, Inc.

InitProcMenu says it will go away after the application is done.  I want this
to patch the whole system.  Will InitProcMenu work?

Thanks...

Brad Morris
[e-mail]

+++++++++++++++++++++++++++

From: [e-mail] (Keith Rollin)
Date: 20 Sep 92 23:25:44 GMT
Organization: Taligent

In article <[e-mail]>,
[e-mail] (Brad Morris) wrote:
>
>In article <[e-mail]> [e-mail] (Keith Rollin) writes:
>>In article <[e-mail]>,
>>[e-mail] (Brad Morris) wrote:
>>>
>>> I am trying to write some code to patch the MBDF.  I know about the MBDF handle
>>> in low memory, but how to I stop LoadResource from loading the Apple MBDF
>>> over mine.  I am kind of new at mucking around in this way.  Thanks.
>>>
>>
>>Won't InitProcMenu work? When the Menu Manager calls LoadResource, I think
>>it doesn't it with the res ID in the MenuList, which is set by the value
>>passed to InitProcMenu.
>
>InitProcMenu says it will go away after the application is done.  I want this
>to patch the whole system.  Will InitProcMenu work?


I patch GetResource for globally replacing system resources. Once the
system has a handle to your resource, LoadResource will continue to get
your resource.

In the following snippet:

o "gMyRefNum" is the resource refNum for my INIT, which holds my MBDF
o My INIT opens itself on the first call to InitAllPacks, and reshuffles
the
  resource chain so that it appears behind the System File.
o MyGetResource saves extra registers because of the comment on page I-113
  of IM.
o "oldGetResource" is a global variable holding the address returned by
  GetToolTrapAddress when I patched GetResource.
o I used THINK C, allowing me the use of A4 globals and inline assembly.


static pascal Handle    MyGetResource(ResType resType, short resID)
{
    short    oldResFile, newResFile;
    Handle    result;

    asm {
        movem.l    a1-a3/d1-d7,-(sp)
    }

    SetUpA4();

    newResFile = oldResFile = -1;

    if (gMyRefNum != 0) {
        //
        // If anyone ever asks for the standard MBDF, give them ours.
        //
        if (resType == 'MBDF' && resID == 0) {
            newResFile = gMyRefNum;
            resID = 1000;
        }
    }

    if (newResFile != -1) {
        oldResFile = CurResFile();
        UseResFile(newResFile);
    }

    result = oldGetResource(resType, resID);

    if (oldResFile != -1)
        UseResFile(oldResFile);

    RestoreA4();

    asm {
        movem.l (sp)+,a1-a3/d1-d7
    }

    return result;
}

- -----
Keith Rollin
Phantom Programmer
Taligent, Inc.

---------------------------

From: [e-mail] (Ralph Gonzalez)
Subject: SUIT - anyone try it? (Simple User Interface Toolkit)
Date: 17 Sep 92 21:53:54 GMT
Organization: Rutgers Univ., New Brunswick, N.J.


Has anyone tried the Mac version of SUIT? (Description below.) I tried
the demo and it locked up on me. It sounds terrific, if it really
works!

- -Ralph

- --------------------------------------------------------------
INTRODUCTION: WHAT IS SUIT?
===================================
Welcome to SUIT, Simple User Interface Toolkit.

SUIT is a library of interface tools developed at the University of
Virginia to help C programmers create sophisticated mouse based
interfaces without the lengthy learning period associated with
traditional user interface toolkits. Ease of learning and fast ramp up
time is central to SUIT's design. The SUIT tutorial is designed to
make the user productive in under two hours.

Also central to SUIT design is portability. SUIT programs currently
run without changes to the source code on the following platforms:
    o IBM PC
    o Macintosh
    o Sun3
    o Sun4 (SparcStation)
    o SGI (Silicon Graphics IRIS workstations)
    o DECstation
    o HP

[copied from SUIT readme file, stuff deleted...]
- --
Ralph Gonzalez, Computer Science, Rutgers Univ., Camden, NJ
Phone: [phone]; Internet: [e-mail]
- --

+++++++++++++++++++++++++++

From: [e-mail] (Ralph Gonzalez)
Date: 17 Sep 92 22:01:45 GMT
Organization: Rutgers Univ., New Brunswick, N.J.

Sorry, I forgot to mention a very important fact about SUIT -- it is
free to educational institutions. Below is more info from their
README file, including the long version of their downloading
instructions!

- --------------------------------------------------
WHO CAN GET SUIT?
==============================
SUIT, including all its source code, is available without charge
to Universities and other non-profit institutions.  For-profit
organizations can send email to

    [e-mail]

to find out how they can help support graduate education in America.

WHAT DO I NEED AT MY SITE IN ORDER TO USE SUIT?
===================================================
    This all depends on the platform you will use:

    X WINDOWS:
        You will need at least X11R4 and gcc 2.1 or later.
        Or any ANSI-compatible C compiler.
        (If all you have is gcc 1.37.X, send us mail.)

    MAC:
        Think C 5.0

    DOS:
        DOS version 5.0 and Borland C++ version 3.1

    WINDOWS:
        Microsoft Windows 3.1 and Borland C++ version 3.1


HOW TO GET THE SUIT DISTRIBUTION
========================================
SUIT is available through anonymous ftp from
uvacs.cs.virginia.edu (128.143.8.29). Each SUIT distribution
package comes with full source code and documentation, though
as explained below, the source and docs are available separately
as well for those attempting to port SUIT to an architecture we do not
yet support. To set a standard SUIT distribution package for your
machine:


1.) On your system, make a directory that will hold the
distribution. For example, in your home directory type:

        mkdir suit

The process of installing the SUIT distribution causes SUIT to
create a new directory underneath the one you've created here.

2.) Change your current directory to this new location:

        cd suit

3.) Type the following command:

        ftp 128.143.8.29

 You should see something that looks like:

        Connected to 128.143.8.29.
        220 uvacs FTP server (SunOS 4.1) ready.
        Name (128.143.8.29:CookieMonster):

    where "CookieMonster" is your login ID.


4.) At this prompt, type:

        anonymous

    You should see something like this:

        331 Guest login ok, send ident as password.
        Password:

5.) Please type in your local login ID as a courtesy. This will not be
echoed back to you, so don't panic.
    You will see:

        230 Guest login ok, access restrictions apply.
        ftp>

6.) cd into the SUIT directory by typing:

        cd /pub/suit/distribution

7.) cd into the directory named after the hardware platform
    you intend to use:

    cd <machine_type>
    where <machine_type> is one of:

        sparc
        sun3
        sgi
        rs6000
    for example:
        cd sparc
            OR
        cd sun3
            ETC.

8.) VERY IMPORTANT: set the ftp transfer to use binary mode
    Type:
        binary

9.) transfer the archive
    Type:
        get <machine_type>.tar.Z

        for example:
            get sparc.tar.Z
                OR
            get sun3.tar.Z
                ETC.

    This file is VERY large. Expect it to take
    several minutes to come over.

10.) leave ftp
    Type:
        quit

11.) uncompress the archive
    Type:
    uncompress < <machine_type>.tar.Z | tar xfh -

    for example:
        uncompress < sparc.tar.Z | tar xfh -

12.) CONGRATULATIONS! You've got yourself the SUIT library and header
files! You can now safely remove the <machine_name>.tar file if you so
desire.

13.) Follow the directions in the top level README file to prepare
the SUIT distrbution for your site.


GETTING SUIT SOURCE
===========================
    Full source code comes with each distribution package of SUIT
    (same source for all architectures).

    IF YOU ONLY WANT THE SOURCE, you can ftp it from uvacs, as
    described above

        ftp uvacs.cs.virginia.edu
        (Be sure to use binary transfer)

    in the file called

        /pub/suit/distribution/JustSource/src.tar.Z



GETTING THE SUIT REFERENCE MANUAL
=========================================
    Each standard distribution package of SUIT comes with a
    complete reference manual which describes the SUIT library
    calls. In the standard distribution, the manual comes in
    the form of a VERY long    postscript file that prints out
    from last page to first.

    If it is more convenient for you to print the manual out from
    first page to last, or if you need just individual reference
    manual chapters, you can ftp the individual files from uvacs,
    as explained above. The files are in:

        /pub/suit/distribution/JustDocs/RefManBySections.tar.Z

    Again, be sure to use binary mode when getting this file.
    (type "binary" at the ftp prompt before typing "get")


ACKNOWLEDGEMENTS
========================

    Thanks for SUIT are due to its original author, Nathaniel Young, and
    to Roderic Collins, Matt Conway, Jim Defay, Pramod Dwivedi, Robert
    DeLine, Brandon Furlich, Rich Gossweiler, Chris Long, William
    McClennan, Kim Passarella, and Randy Pausch. This work was supported
    in part by the National Science Foundation, the United Cerebral Palsy
    Foundation, the Virginia Engineering Foundation, the Virginia Center
    for Innovative Technology, and SAIC.

    TELL US WHAT YOU THINK:
    We would like to hear from you: if you have
    any comments about SUIT, please send electronic mail to

        [e-mail]

    We are very interested in your comments as well as your reports of
    errors, unclear sections, or omissions you find in any part of SUIT.

    SUIT (c) 1990, 1991 , 1992
    Copyright Rector and Visitors of the University of Virginia


- --
Ralph Gonzalez, Computer Science, Rutgers Univ., Camden, NJ
Phone: [phone]; Internet: [e-mail]
- --

+++++++++++++++++++++++++++

From: [e-mail] (Jess M Holle)
Organization: Purdue University Engineering Computer Network
Date: Fri, 18 Sep 92 01:52:32 GMT

I tried the demo from SUIT briefly.  It was sufficiently slow to convince
me not to spend any more time looking at the package.

Jess Holle

+++++++++++++++++++++++++++

From: [e-mail] (Pete Gontier)
Date: 18 Sep 92 04:29:12 GMT
Organization: cellular

[e-mail] (Ralph Gonzalez) writes:

>Has anyone tried the Mac version of SUIT?

Yup. Turns out it's not as wonderful as it says it is.
I was under the impression that it defined a relatively high-
level API which used the native API of each platform it
supported, so that buttons would look like Mac buttons on
the Mac, Windows buttons under (gag) Windows, etc.

What I saw was somebody defining their own GUI and then
using the native graphics primitives to draw and run it.
Basically, they did all their interface elements with
QuickDraw instead of the Control Manager, etc. And it was
real slow, too.

I dunno, perhaps it does serve their purposes well. They're
not trying to provide an ISV toolkit, after all.
- --
 Pete Gontier // EC Technology // [e-mail]

+++++++++++++++++++++++++++

From: [e-mail] (Brent)
Organization: Texas A&M Univ., Inc.
Date: Fri, 18 Sep 1992 05:24:23 GMT

[e-mail] (Jess M Holle) writes:
|I tried the demo from SUIT briefly.  It was sufficiently slow to convince
|me not to spend any more time looking at the package.

I have it on my IIsi and it still crawls along.  Especially the constant
redrawing when you hold the mouse button down in a scroll bar.  Geez.

It crashed on me several times (the demo, that is) but a few of the
crashes were because of the underlying graphics they used to draw everything.
Since they relied on the SRGP (Simple Raster Graphics Package, see Foley,
Van Dam, et al) which itself is buggy, SUIT is buggy also.

SUIT is a *great* idea -- they are doing for ALL windowing interfaces what
Motif did for X.  I think that, if they get SRGP fixed and sped up, then
SUIT will be a good thing, or at least, usable.  On the up-side, SUIT
is new and changes will be made.  Hopefully soon.

- -Brent

+++++++++++++++++++++++++++

From: [e-mail] (Scott Boyd)
Date: 20 Sep 92 00:06:59 GMT
Organization: Apple Computer Inc.

In article <[e-mail]>, [e-mail]
(Brent) wrote:
>
> [e-mail] (Jess M Holle) writes:
> |I tried the demo from SUIT briefly.  It was sufficiently slow to convince
> |me not to spend any more time looking at the package.
>
> I have it on my IIsi and it still crawls along.  Especially the constant
> redrawing when you hold the mouse button down in a scroll bar.  Geez.
>
> It crashed on me several times (the demo, that is) but a few of the
> crashes were because of the underlying graphics they used to draw everything.
> Since they relied on the SRGP (Simple Raster Graphics Package, see Foley,
> Van Dam, et al) which itself is buggy, SUIT is buggy also.
>
> SUIT is a *great* idea -- they are doing for ALL windowing interfaces what
> Motif did for X.  I think that, if they get SRGP fixed and sped up, then
> SUIT will be a good thing, or at least, usable.  On the up-side, SUIT
> is new and changes will be made.  Hopefully soon.
>
> -Brent

I was pretty disappointed with it.  Slow, clunky, lots of unnecessary
redraw (aka flicker), and so foreign relative to the Macintosh interface
as to be nearly unusable.  I, too, anticipated that it would use the
Mac interface elements where possible, but they nearly completely
abandoned it.  I was very surprised that the *only* menu choice they
provided was to *let* you resize the window!

I wish them well, but I hope they choose to avail themselves of
what's there, or that they put some more effort into performance
and usability.  I'm not that concerned that their interface is so
foreign, but it's odd to strike off in a new direction if you're
not offering some considerable advantage in doing so.

scott
[e-mail]

Disclaimer:  personal opinion

+++++++++++++++++++++++++++

From: [e-mail] (Glenn S. Tenney)
Date: 20 Sep 92 09:11:56 GMT
Organization: Netcom - Online Communication Services (408 241-9760 guest)

In article <[e-mail]> [e-mail] (Jon Wdtte) writes:
> ...
>Furthermore, even if SUIT is bug-free (which I doubt) it's still affected
>by SRGPs bugs. THIS IS NOT COMMERCIAL_QUALITY CODE, FOLKS, even though
>the license fee they want for it is $25,000.
> ...

I was flabbergasted to get email from the SUIT people saying
that for any non-university to USE their code you'd have to
pay $25,000 site license fee.  They want to fund a grad student
with the money and literally don't want to deal with anyone
who can't afford it.

SUIT *might* be interesting, but for $25,000 a company can HIRE
someone to write it from scratch.

As an independent, there is no way on earth I can pay $25K.

Aside from any performance problems, it looks like something to
avoid.

- --
Glenn Tenney AA6ER
voice: [phone] fax: [phone]
[e-mail]

+++++++++++++++++++++++++++

From: [e-mail] (Amanda Walker)
Date: 19 Sep 92 10:49:10 GMT
Organization: InterCon Systems Corporation

[e-mail] (Ralph Gonzalez) writes:
> Has anyone tried the Mac version of SUIT? (Description below.) I tried
> the demo and it locked up on me. It sounds terrific, if it really
> works!

I got it to work, but on my Quadra 700 it was still much too slow to consider
using in any kind of commercial quality product.  I was also annoyed that it
does not conform the Apple User Interface guidelines.  Any multi-platform GUI
toolkit should provide the same general performance as a native application
and conform to the platform's look and feel.


Amanda Walker <[e-mail]>

+++++++++++++++++++++++++++

From: [e-mail] (Brent)
Date: 20 Sep 92 19:32:17 GMT
Organization: Texas A&M Univ., Inc.

[e-mail] (Scott Boyd) writes:
|In article <[e-mail]>, [e-mail]
|(Brent) wrote:
|>
|> SUIT is a *great* idea -- they are doing for ALL windowing interfaces what
|> Motif did for X.  I think that, if they get SRGP fixed and sped up, then
|> SUIT will be a good thing, or at least, usable.  On the up-side, SUIT
|> is new and changes will be made.  Hopefully soon.
|
|I was pretty disappointed with it.  Slow, clunky, lots of unnecessary
|redraw (aka flicker), and so foreign relative to the Macintosh interface
|as to be nearly unusable.

I'll agree: it was extremely slow, it has lots of flicker (like what I
mentioned in my original post - about holding the mouse button down in a
scroll bar), BUT, even though the interface looks different, the controls
such as buttons and scroll bars worked the same.  IMO, it doesn't matter
what the actual interface components look like, but how the user is able
to interact with them.  What I mean is, a scroll bar is a scroll bar if
it has two arrows and a thumb that work as I know.  I don't care if it's
a mac-style 1 pixel wide frame for the scroll bar or a 3D, 3 color job
(ala SUIT or Motif).

My point is that even though the interface looked different from the mac's,
it worked the same.  (The popup menu didn't work exactly like a mac's, but
worked just like Motif.)

|  I, too, anticipated that it would use the
|Mac interface elements where possible, but they nearly completely
|abandoned it.

That's the problem with making a totally portable system:  to avoid
a complex set of platform-specific source code, you need to start from
the fundamentals and build up.  The fundamental here is SRGP, unfortunately.

|I wish them well, but I hope they choose to avail themselves of
|what's there, or that they put some more effort into performance
|and usability.  I'm not that concerned that their interface is so
|foreign, but it's odd to strike off in a new direction if you're
|not offering some considerable advantage in doing so.

Well, they are offering an advantage, and a practical one at that.  What
they are offering is a decent-looking user interface that can be used
on a variety of platforms with NO CHANGES to a program's source code.
Is this practical for everybody? No.  It is practical for people who, for
example, are in school and must develop programs to run on different
machines.

I'm not totally defending SUIT.  It is far from perfect, it's too slow
and bulky (check out the demo program's size) and it crashes often.
However, their principle idea is what I'm supporting - you can add a
decent interface to a program easily.

- -Brent

P.S.  Does anyone know if the TranSkel packages are still available via
 ftp?  This package takes a SUIT-like approach to adding an interface to
 a program AND it uses the standard Mac components.  If anyone knows
 where I may find it, please reply.
- --
- ------------------------------------------------------------------------------
Brent P. Burton, N5VMG                          Department of Computer Science
[e-mail]                                   Texas A&M University
       What's a typical family value?  Getting a good buy at WalMart.

+++++++++++++++++++++++++++

From: [e-mail] (Kent Sandvik)
Date: 20 Sep 92 19:12:40 GMT
Organization: Apple

In article <[e-mail]>, [e-mail] (Glenn S. Tenney)
wrote:
> I was flabbergasted to get email from the SUIT people saying
> that for any non-university to USE their code you'd have to
> pay $25,000 site license fee.  They want to fund a grad student
> with the money and literally don't want to deal with anyone
> who can't afford it.

I'm also amazed that we don't for instance write a similar toolkit
as a form of public shareware, take an existing framework that looks
promising, use the skeleton and write operating system/graphics specific
modules for various other platforms (Mac, Windows, Motif...).

If this approach works well with for instance the Gnu tools and compilers,
why not with frameworks as well? This is where I hope universities
would think about publishing code and attributing for public domain
work -- this because we that work in ugly commercial companies are
always pushed by profit margins and economical realities. Not that
universities have this problem as well.

Kent

"You should really just relax" -MST3K
- -------------------
Kent Sandvik (UUCP: ....!apple!ksand; INTERNET: [e-mail])
DISCLAIMER: Private activities on the Net.

+++++++++++++++++++++++++++

From: [e-mail] (Quinn)
Date: 21 Sep 92 02:00:54 GMT
Organization: The University of Western Australia

In article <[e-mail]> Ralph
Gonzalez, [e-mail] writes:
>Has anyone tried the Mac version of SUIT? (Description below.) I tried
>the demo and it locked up on me. It sounds terrific, if it really
>works!

We got the demo to work but quickly ran screaming from the room.
Sorry but IMHO having to put the pointer inside a text field so
that you can type in it doesn't make a Mac application.

Basically it would appear that SUIT attempts to provide OS
transparency at too low a level.  For example it doesn't use the
Mac toolbox to draw or track any of the dialog controls, it does
all the work itself.  While that makes it easier to port (because
you only have to port the drawing primitives) it makes for
*extremely* un-Mac-like (if you'll pardon the clumsy expression)
applications.

Quinn "The Eskimo!"      <[e-mail]>     "Support HAVOC!"
Department of Computer Science, The University of Western Australia
  -- And the scroll bars -- can anyone say ugly!?!

---------------------------

From: [e-mail] ( Philippe Cinquin)
Subject: Is a resource fork already open?
Date: 7 Sep 92 11:48:55 GMT
Organization: IMAG Institute, University of Grenoble, France

Sorry if this is a stupid question, but how do you know if the resource fork of
a file is already open?

Thanks for your replies. If you email please do so at "[e-mail]".

+++++++++++++++++++++++++++

From: [e-mail] (Kent Sandvik)
Date: 7 Sep 92 18:24:33 GMT
Organization: Apple

In article <[e-mail]>, [e-mail] ( Philippe Cinquin) wrote:
>
> Sorry if this is a stupid question, but how do you know if the resource fork of
> a file is already open?

This is Labor day, and I'm the single idiot working here at DTS,
so I couldn't verify if my ramblings are correct or not. Anyway,
OpenRFPerm is the preferred way to open a resource fork for multiple
read-only accesses.

Under MultiFinder, OpenRFPerm will not open a specified file twice
with write access. It will return a -1 and sets ResError to -49
(opWrErr). So I guess that's one way to check out if any other
applications have the resource fork of a special file open for
writing. I assume we are dealing with a multiple updating of resources
(like preferences) synchronization problem.

Just my speculation, I'm no Resource Manager guru.
Kent


"I would rather have a thousands idiots attacking my position, than
have one idiot helping to defend it."    [Paraphrased from Voltaire]
- -------------------
Kent Sandvik (UUCP: ....!apple!ksand; INTERNET: [e-mail])
DISCLAIMER: Private activities on the Net.

+++++++++++++++++++++++++++

From: [e-mail] (Lawrence D'Oliveiro, Waikato University)
Date: 8 Sep 92 15:35:20 +1200
Organization: University of Waikato, Hamilton, New Zealand

In article <[e-mail]>, [e-mail] ( Philippe Cinquin) writes:
> Sorry if this is a stupid question, but how do you know if the resource fork of
> a file is already open?

If a file is already open by somebody else, you'll get an error if you try
opening it in a mode that's incompatible with the other person's open mode.

But I suspect you're really asking what happens when you open a resource file
twice from the same application. The answer is, you will get the same file
refnum back the second time. So how do you tell that this is happened? It can
be done, without too much low-level messing about.

The Resource Manager maintains a chain of currently-open resource files.
It loads the "resource map" structure from each file into memory, and fills
in a link field to chain all the resource maps together. There are two
important low-memory globals that are used for this:

    TopMapHndl -- handle to the first resource map in the chain
    CurMap -- refnum of the "current" resource file (returned by
        CurResFile, can be changed with UseResFile to point anywhere
        along the chain).

Supposing the state of your resource chain is like this:

    TopMapHndl --> map for res file 2 --> map for res file 1
    CurMap -- don't care

And you open resource file 3, which wasn't previously open. The resource
chain now becomes this:

    TopMapHndl --> map for res file 3 --> map for res file 2 -->
                          map for res file 1
    CurMap -- iorefnum for res file 3

If, on the other hand, you try reopening res file 2, you get this
situation:

    TopMapHndl --> map for res file 2 --> map for res file 1
    CurMap -- iorefnum for res file 2

And if you try reopening res file 1, you get this:

    TopMapHndl --> map for res file 2 --> map for res file 1
    CurMap -- iorefnum for res file 1

In summary:

    * If you open a resource file that wasn't previously open, its
      resource map gets prepended to the top of the chain, and TopMapHndl
      is set to point to it.
    * If you reopen a resource file that was already open, TopMapHndl
      is unchanged.
    * Every time you open a resource file, whether it was previously open
      or not, CurMap is updated to hold the iorefnum of that resource file.

So here's how to tell, when you open a resource file, whether you really
opened it or not. First, some useful definitions (this is all in Modula-2,
by the way):

    TYPE
    IORefNum = INTEGER;

    PROCEDURE GetTopMapHndl() : (*Handle*) ADDRESS;
     (* returns the current value of TopMapHndl global. *)

    CODE
        02EB8H, 00A50H; (* move.l TopMapHndl, (sp) *)

    PROCEDURE GetTopMap() : IORefNum;
      (* returns the reference number of the last-opened resource file. *)

    VAR
        TempHandle : Handle;
        TempPtr : POINTER TO IORefNum;

    BEGIN
    TempHandle := GetTopMapHndl();
    TempPtr := TempHandle^ + 20;
    RETURN
        TempPtr^
    END GetTopMap;

Now here's an example code fragment that opens a resource file:

      (* get information about current state of resource chain *)
    PreviousResFile := CurResFile();
    PreviousTop := GetTopMap();

      (* open resource file with OpenResFile, OpenRFPerm or whatever, e g *)
    TheResFile := OpenRFPerm(FileName, VRefNum, Permission);

    ReallyOpened :=
        (TheResFile = GetTopMap())
        AND
        (TheResFile <> PreviousTop)

And to close the resource file (but only if it was really opened by you) and
leave things the way they were before:

    IF ReallyOpened THEN
        CloseResFile(TheResFile)
    END (*IF*);
    UseResFile(PreviousResFile)

I have successfully used this code to do things to my running system file.
And I haven't had a crash yet. crash yet. crash yet.

Lawrence D'Oliveiro                       fone: [phone]
Computer Services Dept                     fax: [phone]
University of Waikato            electric mail: [e-mail]
Hamilton, New Zealand    37^ 47' 26" S, 175^ 19' 7" E, GMT+12:00
"Well, perhaps that is because Apple has not yet released any future versions
of the System software." -- Amanda Walker

+++++++++++++++++++++++++++

From: [e-mail] (Matthias Neeracher)
Organization: Integrated Systems Laboratory, ETH, Zurich
Date: Tue, 8 Sep 1992 12:07:09 GMT

In article <[e-mail]> [e-mail] (Lawrence D'Oliveiro, Waikato University) writes:
>In article <[e-mail]>, [e-mail] ( Philippe Cinquin) writes:
>> Sorry if this is a stupid question, but how do you know if the resource fork of
>> a file is already open?
>
>If a file is already open by somebody else, you'll get an error if you try
>opening it in a mode that's incompatible with the other person's open mode.
>
>But I suspect you're really asking what happens when you open a resource file
>twice from the same application. The answer is, you will get the same file
>refnum back the second time. So how do you tell that this is happened? It can
>be done, without too much low-level messing about.

>[Low level messing about deleted :-]

Excuse me, but am I missing something obvious or is there a much simpler way to
determine if the resource fork is already open?

PBGetCatInfo returns a field called ioFlAttrib, and according to
_Inside Macintosh:Files_, bit 2 of that field is set if the resource
fork is open.

Matthias

- -----
Matthias Neeracher                                   [e-mail]
 "You must have picked up that copy of Scarlett instead of Inside Mac
  when you tried to find the right call..." -- Keith Rollin

+++++++++++++++++++++++++++

From: [e-mail] (Kent Borg)
Date: 8 Sep 92 20:09:46 GMT
Organization: Camex Inc., Boston MA

In article <[e-mail]> [e-mail] (Lawrence D'Oliveiro, Waikato University) writes:
>In article <[e-mail]>, [e-mail] ( Philippe Cinquin) writes:
>> Sorry if this is a stupid question, but how do you know if the resource fork of
>> a file is already open?
>
>If a file is already open by somebody else, you'll get an error if you try
>opening it in a mode that's incompatible with the other person's open mode.
>
>But I suspect you're really asking what happens when you open a resource file
>twice from the same application. The answer is, you will get the same file
>refnum back the second time. So how do you tell that this is happened? It can
>be done, without too much low-level messing about.
>
>The Resource Manager maintains a chain of currently-open resource files.
>It loads the "resource map" structure from each file into memory, and fills
>in a link field to chain all the resource maps together. There are two
>important low-memory globals that are used for this:
>
>    TopMapHndl -- handle to the first resource map in the chain
>    CurMap -- refnum of the "current" resource file (returned by
>        CurResFile, can be changed with UseResFile to point anywhere
>        along the chain).

Um, when the obvious stares me in the face but is missed by the likes
of Lawrence D'Oliveiro, I tend to assume I am wrong.  However, I just
did this and if my solution is busted I want to know about it, so it
is limb climbing time.

If you want to know whether a file is already open, why not ask by
calling PBGetFInfo()?  II-115: "If the file is open, the reference
number of the first access path found is returned in ioFRefNum...".

On further critical reading, the phrase "first access path found"
makes me wonder.  Might it be the same as the "first resource file in
the chain".  No, because PBGetFInfo() doesn't know which interests
me--or does it?

Is it what I need?  If a different application has the file open, do I
get that app's refnum?

OK, Lawrence, please explain this to me, and now that I have done my
best to confuse the net.world, explain it to them too.

Thanks bunches.


- --
Kent Borg            [e-mail] or (when it is *working*) [e-mail]
                                            H:[phone]  W:[phone]
As always, things look better when some costs are left out.
                              -Economist 3-28-92 p. 94

+++++++++++++++++++++++++++

From: [e-mail] (Keith Rollin)
Date: 8 Sep 92 21:43:28 GMT
Organization: Taligent

In article <[e-mail]>, [e-mail] (Matthias
Neeracher) writes:
>
> In article <[e-mail]> [e-mail] (Lawrence
D'Oliveiro, Waikato University) writes:
> >In article <[e-mail]>, [e-mail] ( Philippe Cinquin) writes:
> >> Sorry if this is a stupid question, but how do you know if the resource
fork of
> >> a file is already open?
> >
> >If a file is already open by somebody else, you'll get an error if you try
> >opening it in a mode that's incompatible with the other person's open mode.
> >
> >But I suspect you're really asking what happens when you open a resource file
> >twice from the same application. The answer is, you will get the same file
> >refnum back the second time. So how do you tell that this is happened? It can
> >be done, without too much low-level messing about.
>
> >[Low level messing about deleted :-]
>
> Excuse me, but am I missing something obvious or is there a much simpler way
to
> determine if the resource fork is already open?
>
> PBGetCatInfo returns a field called ioFlAttrib, and according to
> _Inside Macintosh:Files_, bit 2 of that field is set if the resource
> fork is open.

Sometimes you want to know if the resource fork is open in _your_ application.
Calling PBGetCatInfo will tell you if the file is open within _any_ application.
The method Lawrence posted is the proper method.

(Another method, which is more fun but which is very likely to break at some
time in the future is to walk the resource chain, pull out refnums, call
GetFCBInfo on them, and see if the file you are interested in is returned.)

- --
Keith Rollin
Phantom Programmer
Taligent, Inc.

+++++++++++++++++++++++++++

From: [e-mail] (Kent Sandvik)
Date: 8 Sep 92 16:35:34 GMT
Organization: Apple

Greg Robbins mentioned to me that the DTS Q&A stack contains the
needed information to find out when the resource fork is open
(silly me, have to add the stack to my On Location database).

The canonical way is to check if the resource file is open is to
call PBGetCatInfo and check bit 2 of the ioFilAttrib field. Ugh.

Kent
"I would rather have a thousands idiots attacking my position, than
have one idiot helping to defend it."    [Paraphrased from Voltaire]
- -------------------
Kent Sandvik (UUCP: ....!apple!ksand; INTERNET: [e-mail])
DISCLAIMER: Private activities on the Net.

+++++++++++++++++++++++++++

From: [e-mail] (Charles B. Cranston)
Date: 8 Sep 92 23:32:07 GMT
Organization: UM Home for the Terminally Analytical

In article <[e-mail]>, [e-mail] (Keith Rollin)
wrote:

> Sometimes you want to know if the resource fork is open in _your_
> application. Calling PBGetCatInfo will tell you if the file is open
> within _any_ application. The method Lawrence posted is the proper method.
>
> (Another method, which is more fun but which is very likely to break at some
> time in the future is to walk the resource chain, pull out refnums, call
> GetFCBInfo on them, and see if the file you are interested in is returned.)

Yeah, I missed the ioFlAttib too, since the doc on the field is so far
away from the doc on the trap.  I came up with the follwing:

Do GetCatInfo, if ioFRefNum is zero then no access path onto either fork
is open, so the resource fork is not open.

Else use a series of indexed GetFCBInfo calls to look for one that
matches ParID and NamePtr and has bit 1 set in ioFCBFlags which says
it is a resource fork path.  I think this is a slightly cleaner version
of what Keith jokingly suggests...

[e-mail]     -KA3ZDF

+++++++++++++++++++++++++++

From: [e-mail] (Lawrence D'Oliveiro, Waikato University)
Date: 10 Sep 92 03:27:51 GMT
Organization: University of Waikato, Hamilton, New Zealand

In article <[e-mail]>, [e-mail] (Kent Sandvik) writes:
> The canonical way is to check if the resource file is open is to
> call PBGetCatInfo and check bit 2 of the ioFilAttrib field. Ugh.

Yeah, but that doesn't tell if you if it was opened by the Resource Manager.
All it tells you is that someone has used OpenRF.

Lawrence D'Oliveiro                       fone: [phone]
Computer Services Dept                     fax: [phone]
University of Waikato            electric mail: [e-mail]
Hamilton, New Zealand    37^ 47' 26" S, 175^ 19' 7" E, GMT+12:00

+++++++++++++++++++++++++++

From: [e-mail] (Lawrence D'Oliveiro, Waikato University)
Date: 9 Sep 92 15:41:51 +1200
Organization: University of Waikato, Hamilton, New Zealand

In article <[e-mail]>, I posted some code
showing you how to open a resource file and detect if it was already open.

That code can actually be simplified a little. Recall that TopMapHndl only
changes if you open a resource file that wasn't already open. So the
ReallyOpened condition can be shortened to just "GetTopMap() <> PreviousTop".

And while we're at it, we don't really need the GetTopMap routine at all.
Just check the value of TopMapHndl itself. And in Modula-2, you can access
low-memory globals as based variables.

Putting this altogether (and noting that PreviousTop is now a Handle, not
an IORefNum), the new code is:

    TYPE
    IORefNum = INTEGER;

    VAR
    TopMapHndl [00A50H] : Handle;

Code to open the file:

      (* get information about current state of resource chain *)
    PreviousResFile := CurResFile();
    PreviousTop := TopMapHndl;
      (* open resource file with OpenResFile, OpenRFPerm or whatever, e g *)
    TheResFile := OpenRFPerm(FileName, VRefNum, Permission);
    ReallyOpened := TopMapHndl <> PreviousTop

Code to restore things as they were:

    IF ReallyOpened THEN
        CloseResFile(TheResFile)
    END (*IF*);
    UseResFile(PreviousResFile)

Sometimes it takes the glare of publicity to get you to think out the *proper*
way to do something you might have been doing for years...

Lawrence D'Oliveiro                       fone: [phone]
Computer Services Dept                     fax: [phone]
University of Waikato            electric mail: [e-mail]
Hamilton, New Zealand    37^ 47' 26" S, 175^ 19' 7" E, GMT+12:00

+++++++++++++++++++++++++++

From: [e-mail] (Jim Reekes)
Date: 11 Sep 92 21:39:07 GMT
Organization: Apple Computer, Inc.

In article <[e-mail]>, [e-mail]
(Lawrence D'Oliveiro, Waikato University) wrote:
>
> In article <[e-mail]>, [e-mail] ( Philippe Cinquin) writes:
> > Sorry if this is a stupid question, but how do you know if the resource fork of
> > a file is already open?
>
> If a file is already open by somebody else, you'll get an error if you try
> opening it in a mode that's incompatible with the other person's open mode.
>
> But I suspect you're really asking what happens when you open a resource file
> twice from the same application. The answer is, you will get the same file
> refnum back the second time. So how do you tell that this is happened? It can
> be done, without too much low-level messing about.
>
> The Resource Manager maintains a chain of currently-open resource files.
> It loads the "resource map" structure from each file into memory, and fills
> in a link field to chain all the resource maps together. There are two
> important low-memory globals that are used for this:
>
>     TopMapHndl -- handle to the first resource map in the chain
>     CurMap -- refnum of the "current" resource file (returned by
>         CurResFile, can be changed with UseResFile to point anywhere
>         along the chain).
>
> **** some stuff deleted ****

The best approach to take is to avoid the problem in the first place.


* Stay away from low memory globals

* To determine if a file is already open, use PBGetCatInfo.

* To know when it's safe to close a resource file, make sure you're the
only one that opened it.  This can be done by first checking the ioFlAttrib
from PBGetCatInfo *BEFORE* you open the file.  If it's open, then don't
open is again.  Then you'll know that it's safe to close it.

* If you call OpenRFPerm with read-only, then you'll always get a new
FCB and map.  This means it's safe to close it.

* It's dangerous to have more than one path open to a resource file.
If one user has a read/write path, and a second use has another read-only
path, then the first user can change the file and this means the second
reader is screwed.  The file is corrupted to the 2nd reader's point of
view.

* To make things more complicated, and more dangerous, the System file is
always open and always available to everyone.  You'll always find the
System
map in your application's resource chain.  Additionally, any file below
the System will also be in your chain (fonts, suitcases, input methods,
etc.)
These are files you typically never open directly.  Just call GetResource
and assume it's been opened for you.  This is why system resources have
unique numbers and types.

- -----------------------------------------------------------------------
Jim Reekes, Polterzeitgeist  |     Macintosh Toolbox Engineering
                             |          Sound Manager Expert
Apple Computer, Inc.         | RAll opinions expressed are mine, and do
20525 Mariani Ave. MS: 81-KS |   not necessarily represent those of my
Cupertino, CA 95014          |       employer, Apple Computer Inc.S

+++++++++++++++++++++++++++

From: [e-mail] (Lawrence D'Oliveiro, Waikato University)
Date: 19 Sep 92 06:22:54 GMT
Organization: University of Waikato, Hamilton, New Zealand

In article <REEKES-110992142814@90.10.20.67>, [e-mail] (Jim Reekes) writes:
> In article <[e-mail]>, [e-mail]
> (Lawrence D'Oliveiro, Waikato University) wrote:

[description of technique for opening a resource file and determining if
was already open deleted]

>
> The best approach to take is to avoid the problem in the first place.

The problem is writing robust code for fetching resources from files, and
for putting resources into files.

>
> * Stay away from low memory globals

Unfortunately, this problem cannot be solved without doing this.

>
> * To determine if a file is already open, use PBGetCatInfo.

That just tells you a file is open. It can even tell you a resource fork is
open. It can't tell you whether the file was actually opened by the Resource
Manager.

> * To know when it's safe to close a resource file, make sure you're the
> only one that opened it.  This can be done by first checking the ioFlAttrib
> from PBGetCatInfo *BEFORE* you open the file.  If it's open, then don't
> open is again.  Then you'll know that it's safe to close it.

Duhhh... race conditions? (Async opens, and all that.)

> * If you call OpenRFPerm with read-only, then you'll always get a new
> FCB and map.  This means it's safe to close it.

That's handy to know.

> * To make things more complicated, and more dangerous, the System file is
> always open and always available to everyone.  You'll always find the
> System
> map in your application's resource chain.  Additionally, any file below
> the System will also be in your chain (fonts, suitcases, input methods,
> etc.)
> These are files you typically never open directly.  Just call GetResource
> and assume it's been opened for you.  This is why system resources have
> unique numbers and types.

As I said before, the problem is writing robust code for fetching resources
from files, and for putting resource into files. Ideally, this code should
work no matter what file it is asked to open. Which means, of course, it
has to handle the case where the file has already been opened by the Resource
Manager.

Lawrence D'Oliveiro                       fone: [phone]
Computer Services Dept                     fax: [phone]
University of Waikato            electric mail: [e-mail]
Hamilton, New Zealand    37^ 47' 26" S, 175^ 19' 7" E, GMT+12:00
"While cumbersome Corel is busy gobbling up 30 megabytes of your hard drive,
Windows Draw is getting the job done on a mere 12 megabytes."
                        -- ad in Aug '92 PC Magazine

---------------------------

End of C.S.M.P. Digest
**********************